home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
kermit.columbia.edu
/
kermit.columbia.edu.tar
/
kermit.columbia.edu
/
newsgroups
/
misc.19970929-19971216
/
000051_news@newsmaster….columbia.edu _Sat Oct 4 15:17:56 1997.msg
< prev
next >
Wrap
Internet Message Format
|
1997-12-15
|
5KB
Return-Path: <news@newsmaster.cc.columbia.edu>
Received: from newsmaster.cc.columbia.edu (newsmaster.cc.columbia.edu [128.59.35.30])
by watsun.cc.columbia.edu (8.8.5/8.8.5) with ESMTP id PAA10434
for <kermit.misc@watsun.cc.columbia.edu>; Sat, 4 Oct 1997 15:17:56 -0400 (EDT)
Received: (from news@localhost)
by newsmaster.cc.columbia.edu (8.8.5/8.8.5) id PAA08221
for kermit.misc@watsun; Sat, 4 Oct 1997 15:17:55 -0400 (EDT)
Path: news.columbia.edu!watsun.cc.columbia.edu!fdc
From: fdc@watsun.cc.columbia.edu (Frank da Cruz)
Newsgroups: comp.os.linux.misc,comp.protocols.kermit.misc
Subject: Re: Better FTP than FTP? (Kermit/modem sharing)
Date: 4 Oct 1997 19:17:52 GMT
Organization: Columbia University
Lines: 76
Message-ID: <6164p0$4p0$1@apakabar.cc.columbia.edu>
References: <60cqce$22v$1@merki.connect.com.au> <60rure$sem$1@mercury.mcs.net> <60tn42$fi4$1@apakabar.cc.columbia.edu> <614on6$b18$1@mercury.mcs.net>
NNTP-Posting-Host: watsun.cc.columbia.edu
Keywords: FTP
Xref: news.columbia.edu comp.os.linux.misc:218249 comp.protocols.kermit.misc:7819
In article <614on6$b18$1@mercury.mcs.net>, Leslie Mikesell <les@MCS.COM> wrote:
: In article <60tn42$fi4$1@apakabar.cc.columbia.edu>,
: Frank da Cruz <fdc@watsun.cc.columbia.edu> wrote:
:
: >: I don't think it's crazy to use inetd to start a program with its standard
: >: file descriptors connected to a tcp socket. That's the normal way
: >: to do things if you don't mind the start-up time...
: >:
: >C-Kermit starts very quickly if you tell it to skip reading its
: >initialization file:
:
: What I meant by that was that some programs are run as 'standalone'
: daemons listening directly on certain ports simply to reduce the
: startup time compared to letting inetd accept the connection and
: exec them. Sendmail and httpd normally run standalone, but I
: don't think it would matter for kermit.
:
Kermit can run standalone. If you tell it to "set host * 2000", this
means to wait for a TCP connection to come in on port 2000. But then you
could not use it to make a connection between the TCP side and a modem, since
in its present form C-Kermit can only have one "set host" or "set line"
device open at once.
: >: ...you should be able to start it with a script
: >: that has a stack of:
: >:
: >: set port /dev/xxx1
: >: if success goto got_modem
: >: set port /dev/xxx2
: >: etc...
: >:
: >: to work through a pool of modems that might also be shared for dial-in
: >: and fax use.
: >:
: >: (By the way, how about setting a convention for doing this so all
: >: your other scripts that need a modem can 'take' the file that
: >: finds one?)
: >:
: >What kind of convention would you like to see? Kermit has no way of knowing
: >which devices to use, so executing a command file, as you have suggested,
: >would be just about the only sensible one. In this case the convention
: >might be:
: >
: > kermit -y filename
: >
: >(lowercase "y" = execute "filename" instead of the standard init file).
:
: In my case I ended up with a file /usr/local/lib/kermit/getline.k that
: I kept up to date with the ports with available dial-out modems. Then
: many other dial-out scripts would simply 'take' that file. That keeps
: the other scripts from requiring changes when modems are added, moved
: or deleted, or even when the scripts are moved to different machines.
: Having a 'site-library' directory concept in some example scripts
: might make this approach even more portable.
:
Good idea. In the current version of C-Kermit, the "take" command (which
executes command files) searches a "take path" to find the file whose name
is given if it is not fully specified or in the current directory. The
"take path" is currently hardwired, but it would be a simple matter to make
it user- and/or site-definable. I'll add this to the list.
: >Kermit goes to great lengths to be efficient when it is "in the middle",
: >using buffered, nonblocking i/o on both ends of its connection, within the
: >limits of portability (not all UNIXes have threads, select(), etc).
: >
: >I'd drop everything and fool with this myself if it was in my power to do
: >that, so anybody else who is interested has a guaranteed head start.
:
: I guess I should have suggested it a couple of years ago, but the
: place I was working for bought a terminal server so I ended up
: not needing it.
:
Terminal servers are terrific if you have one and if you can get to it, but
tricks like this come in handy for all sorts of reasons.
- Frank